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FOREWORD 


j This  publication  constitutes  an  invited  paper  presented  at  the 

j "Distributed  Systems — Trends"  session  of  the  Computer  Software  2md 

^ Applications_Cc^ference  (COMPSAC  78)  held  in  Chicago  on  13-lb  Novetnber 

; 1978.  ^e  author's  parent  organization  is  the  Computer  Programming 

j lyivision.  Strategic  Systems  Depeurtment,  Naval  Surface  Weapons  Center. 
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INTRODUCTION  i 

I 

The  U.S.  Navy  is  looking  forward  to  distributed  computer  systems  ^ 

for  the  solution  of  many  of  its  problems  in  shipboaurd  command  2uid  control. 

Like  emy  new  technology,  however,  this  concept  is  creating  its  own  set 
of  problems — problems  that  must  be  looked  at  very  closely,  or  the  ensuing 
chaos  could  be  worse  than  the  present  situation.  This  paper  presents 
I the  Navy's  interest  in  distributed  computer  systems  as  discussed  at  the 

I Navy  Distributed  Computer  Systems  Workshop  held  in  JUne  1977. 

i 

To  present  the  Navy's  interest  in  this  technology,  the  nature  of 
, Navy  systems  and  some  of  the  constraints  created  by  Navy  philosophy  are 

, discussed.  Secondly,  some  of  the  requirements  of  naval  systems  cure 

j presented.  A couple  of  busing  systems  being  investigated  by  the  Navy 

; are  mentioned  briefly,  and  some  of  the  problems  to  be  faced,  as  the  I 

author  views  them,  are  presented.  i 

j 

THE  NATURE  OF  NAVY  SYSTEMS 

The  Navy  did  not  do  very  well  in  the  past  when  it  came  to  putting 
different  systems  aboaurd  a ship  euid  making  them  work  as  a unit.  In  order  | 

to  correct  this  deficiency.  Navy  philosophy  today  considers  the  whole 
; ship,  with  all  of  its  systems,  as  one  unit  called  a combat  system.  This  | | 

is  more  significant  to  Navy  contractors  than  it  may  sound  at  first.  Once,  ’ 

! a developer  could  work  independently  and  build  a system,  such  as  a missile 

i system,  without  being  concerned  about  how  the  other  systems  on  the  ship 

were  going  to  be  configured  or  how  they  were  going  to  be  used.  The  Navy 
I was  then  left  with  the  problem  of  integrating  these  systems  into  eui 

I operational  unit.  Today,  with  the  whole  ship  being  considered  one  unit, 

all  of  the  pieces  of  that  unit  must  be  compatible  and  must  work  together 
to  conduct  the  mission  of  the  ship.  Distributed  systems  technology  can 
I be  the  adhesive  that  bonds  all  the  pieces  together  eUid  permits  them  to 

[ function  as  a unit. 

Figure  1 shows  the  basic  elements  of  one  such  combat  system,  the 
AEGIS  Ships  Combat  System,  which  is  under  development  for  the  Navy. 

Both  the  ship  and  the  weapon  systems  acquisition  are  being  coordinated 
by  the  same  Navy  project  office. 

Most  of  the  component  subsystems  are  not  new,  but  the  idea  of 
integrating  them  into  onri  functioning  combat  system  is  new.  There  will 
be  more  thcui  50  computers  in  the  AEGIS  system,  which  is  not  presently 
a distributed  system  but  the  technology  is  being  considered  for  future 
versions.  It  should  not  take  too  much  knowledge  of  distributed  systems 

technology  to  see  how  helpful  it  would  be  in  integrating  so  many  sub-  , 

E systems  into  2m  operational  combat  system  under  unified  control. 
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The  architecture  shovm  in  Figure  2 is  one  way  that  has  been  proposed 
to  connect  the  pieces  of  a combat  system.  This  architecture  was  conceived 
at  the  Naval  Surface  weapons  Center  (NSWC)  in  response  to  the  new  naval 
ship  "operational  philosophy"  put  forth  by  the  Chief  of  Naval  (^rations 
(CNO) • * This  philosophy  calls  for  a federated  combat  system  in  which 
control  is  by  delegation  and  negation,  a concept  \pdiich  is  not  possible 
with  configurations  on  present  Navy  ships.  Note  that  all  the  sensors 
are  on  one  bus,  the  weapons  on  another  bus,  and  all  the  conoumd  and 
control  information  is  on  a third  bus. 


Figure  1.  AEGIS  Ship  Configuration 


Figure  3 illustrates  another  new  concept  in  ship  design  called  the 
SEA  System  MODification  and  MODernization  by  MODularity  (SEAMOD).** 

The  platform  and  the  payload  are  considered  separate  entities.  The 
platform  consists  of  the  hull,  propulsion,  and  other  equipment  that 
normally  lasts  the  entire  nominal  30-yr  lifetime  of  the  ship.  The  pay- 
load  includes  the  weapons,  sensors,  computers,  command,  control,  and 
communications  equipment,  which  is  usually  replaced  with  more  modern 
equipment  about  every  10  yr. 

One  of  the  keys  to  the  successful  implementation  of  SEAMOD  is  a 
permanent  data  bus  and  electrical  power  distribution  system  installed 
in  the  ship  for  its  lifetime.  In  the  past  during  modernization,  the 
ships  have  essentially  been  gutted  and  rewired  point-to-point.  A Navy 
cruiser  has  approximately  1000  miles  of  ceUsles.  The  cost  of  cable 
acquisition  emd  replacement  during  an  overhaul  is  estimated  at  $35  a foot. 

* CNO  Itr  Ser  031702528  dated  8 Nov  1976,  subject  "Surface  Ship  Combat 
Systems  Operational  Philosophy." 

**  S.E.  Veazey,  "SEAMOD  Combat  Systems  for  Advemced  Platforms,"  Naval 
Engineers  Journal,  February  1978,  p.53. 
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Figure  2.  New  Combat  System  Configuration 


Figure  3.  SEAMOD  Concept 

The  subsystems  are  to  be  built  as  modules,  installed  in  standard 
slots  on  the  hull,  and  connected  into  the  bus  and  power.  One  can  see 
the  importance  of  standard  busing  protocols  and  interfaces  for  such  a 
system. 

The  concept  of  distributed  systems  will  also  find  its  way  into 
naval  aircraft.  Figure  4 illustrates  an  avionics  system  that  has  even 
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more  stringent  space  and  weight  constraints. * Note  that  the  processing 
is  totally  decentralized  in  this  system.  The  bus  is  used  to  communicate 
between  regional  terminals  (RTs);  subsystems  and  other  functions  (F  ) are 
tied  into  the  RTs.  ” 


Navy  systems  are  time-critical  systems  and,  in  some  instances,  real- 
time control  systems.  The  data  upon  which  these  systems  operate  (e.g., 
target  position  data,  own-ship’s  position  data,  and  missile  aiming  data) 
must  be  correlated  in  time  and  are  very  sensitive  to  time  lags. 


NAVY  REQUIREMENTS 

The  nature  of  the  Navy's  systems  and  the  way  in  which  the  Navy 
functions  present  some  rather  stringent  requirements  on  the  design  of 
hardware  and  software.  In  addition  to  the  requirements  discussed  here, 
it  is  also  true  that  all  the  obvious  requirements  of  any  "good"  system 
(e.g.,  ease  of  programming,  low  cost,  user -oriented  design,  etc.)  are 
also  requirements  of  Navy  systems.  Time  and  space  do  not  permit  elab- 
orating on  each  of  these. 

Obviously,  Navy  systems  must  be  reliable.  They  must  also  be  fault 
toleremt.  If  a fault  does  occur  while  a weapon  system  is  firing  at  an 
incoming  missile,  the  system  must  be  able  to  recover  immediately  and 
carry  on  its  function  (fault  toler^mce) . If  one  part  of  a system  becomes 


* W.P.  Warner  and  W.J.  Dejka,  Navy  Distributed  Computer  System  Workshop, 
Naval  Surface  Weapons  Center  Technical  Report  NSWC/DL  TR-3790,  Dahlgren, 
Virginia,  April  1978. 
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inoperable  because  of  battle  damage  or  other  reasons,  the  whole  mission 
must  not  be  aborted.  The  priority  functions  being  performed  by  the 
system  must  be  continued,  even  at  the  expense  of  some  other  less-important 
functions  (graceful  degradation) . 

When  a system  does  break  down,  it  must  be  repaired  by  sailors  and 
not  by  company  customer  engineers  (CEs).  If  a CE  can't  solve  a problem, 
he  calls  in  a factory  expert.  A sailor  1000  miles  from  shore  can't  do 
that.  Deployed  systems  liave  to  be  built  in  such  a way  that  faults  can 
be  isolated  quickly  and  repaired  easily  by  persons  with  a minimum  of 
training  (maintainability) . The  average  time  a sailor  serves  in  this 
capacity  is  4*5  yr. 

It  presently  takes  about  14  yr  from  the  conception  of  a combat 
system  until  that  system  is  seen  in  the  Fleet.  This  fact  implies  that 
the  technology  is  old  before  it  is  implemented.  A typical  weapon 
system  has  a 10-  to  15-yr  operational  life.  It  is  modified  many  times 
during  this  life  cycle  to  expand  its  "computational  capacity"  and  conduct 
additional  or  modified  functions.  Systems  not  developed  with  this  in 
mind  are  extremely  difficult  and  expensive  to  modify  eind  can  take  the 
ship  out  of  operation  for  extended  periods  of  time. 

The  operation  of  Navy  systems  can  involve  large  cimounts  of  data 
and  very  high  data  rates.  During  a full  antisubmarine  operation,  for 
excimple,  data  transmission  rates  of  30  million  bits  per  second  can  be 
required.  The  data  in  these  systems  also  may  have  various  levels  of 
security  classifications  ranging  from  highly  classified  intelligence 
data  to  unclassified  maintenance  information.  All  personnel  aboard  ship 
do  not  have  the  same  level  of  security  clearance  or  need-to-know.  The 
system  must  be  designed  so  that  it  is  possible  to  protect  some  of  the 
data  from  other  operators  in  the  system. 

EXAMPLES  OF  PRESENT  APPROACHES  TO  BUSING 

A key  factor  in  any  distributed  system  is  the  communications  net- 
work. The  following  are  excimples  of  the  different  kinds  of  data  busing 
systems  being  considered  for  Navy  systems. 

One  of  the  busing  systems  is  called  the  Shipboard  Data  Multiplex 
System  (SDMS)  (Figure  5).  There  are  five  physical  buses  in  SDMS,  and 
each  bus  has  its  own  traffic  controller,  which  polls  the  area  multi- 
plexers to  see  if  there  are  any  messages  to  be  transmitted.  Each  bus 
has  four  data  channels  and  a separate  control  channel.  Each  area  multi- 
plexer is  connected  to  every  bus.  To  enhance  the  survivability  of  the 
system  in  case  of  battle  damage,  each  of  the  five  buses  would  be  routed 
the  length  of  the  ship  by  different  paths.  The  system  provides  graceful 
degradation,  since  the  failure  of  one  of  the  buses  does  not  affect  the 
operation  of  the  remainder. 


Honeywell's  experimental  distributed  processor  (XDP)  (Figure  6)  is 
also  being  considered  by  the  Navy.  All  processing  elements  are  tied  into 
the  global  bus  by  bus  interface  units  (BIUs)  at  any  point  on  the  bus. 
Every  BIU  has  a synchronized  clock  counter,  and  each  is  assigned  specific 
clock  times  during  which  it  has  control  of  the  bus.  The  schedule  is 
stored  in  each  BIU  and  can  be  changed  in  the  field.  The  busiest  BIUs  can 
be  assigned  the  greatest  number  of  clock  times. 


Figure  5.  Shipboard  Data  Multiplex  System 
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Figure  6.  Experimental  Distributed  Processor 


The  XDP  was  designed  with  distributed  processing  in  mind.  It  has 
the  capacity  of  associative  addressing  (addresses  the  process,  not  the 
processor,  and  the  location  of  the  process  can  migrate  from  one  processing 
element  to  another) . Honeywell  has  also  developed  an  XDP-type  bus  without 
the  associative  addressing  feature  for  a foreign  Navy. 

Other  developments  include  the  General  Electric  Trident  Trainer  Data 
Mulitplex  System  (TDMS)  and  the  UNIVAC  Shipboard  Integrated  Processing 
and  Display  System  (SHINPADS) . There  are  undoubtedly  several  others. 


SYSTEM  COSTS 

Distributed  systems  show  promise  in  solving  some  of  the  Navy's 
problems,  but  additional  costs  that  cure  not  found  in  a system  with  central 
processing  may  be  incurred.  In  a centralized  system,  the  operating  system 
is  contained  in  only  one  memory.  In  a distributed  system,  at  least  a 
portion  of  the  operating  system  has  to  be  reproduced  in  every  processor, 
taking  up  valuable  system  resources. 

Distributed  systems  also  show  promise  of  improved  reliability  and 
survivability  because  by  their  nature  all  components  need  not  be  centrally 
located.  But  there  are  added  costs  to  making  any  system  survivcible.  A 
system  needs  overall  control,  and  this  requires  the  availability  of  systems 
status  data.  There  are  from  5000  to  10,000  such  pieces  of  systems  data 
in  a combat  system.  In  a distributed  system,  this  data  must  be  stored 
in  more  than  one  processor  or  memory  in  case  the  processor  or  memory 
involved  in  system  control  becomes  inoperable  or  gets  involved  in  a 
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"deadlock"  situation.  This  increases  the  overhead  storage  requirements 
and  can  cause  an  increase  in  the  amount  of  data  to  be  passed  around  the 
system. 

Another  added  cost  is  the  increase  in  software  debugging  problems. 

In  a truly  distributed  system,  functions  are  performed  in  whatever 
processor  is  available.  This  causes  difficulty  in  tracing  the  sources 
of  problems.  Additional  resources  will  have  to  be  allocated  for  a debug- 
ging system. 


UNSOLVED  ISSUES 

The  hardware  technology  issues  needing  solution  are  many  and  are 
not  discussed  in  detail  in  this  paper.  Probably  the  biggest  system 
issue  to  be  solved  is  the  question  of  how  to  control  a distributed  system. 
This  includes  not  only  the  usual  operating  system  functions  but  the 
problem  of  synchronizing  all  of  the  processors  and  the  data  they  produce. 
The  configuration  of  the  system  should  be  completely  transparent  to  the 
application  software  developer  and  not  require  any  action  on  his  part 
to  coordinate  the  system. 

There  are  many  tools  that  need  to  be  developed.  Tools  are  needed 
to  assist  in  making  effective  partitioning  and  distribution  of  the  func- 
tions and  data  involved  in  the  solution  of  the  problem  for  which  the 
system  is  being  developed.  Tools  are  needed  for  system  trade-off  studies 
and  performance  estimation  and  evaluation.  Tools  are  also  needed  for 
our  continuing  problem  of  developing  software,  but  now  it  will  be  com- 
plicated by  the  parallel  computing  characteristic  of  distributed  systems. 


CONCLUSION 


Distributed  systems  technology  holds  many  exciting  possibilites 
for  the  solution  of  Navy  problems,  but  no  one  in  the  Navy  or  elsewhere 
views  distributed  systems  as  a panacea.  Whereas  this  technology  may 
approach  a solution  to  several  problems,  such  as  modifiability  and 
survivability,  it  introduces  a whole  new  set  of  problems  of  its  own. 
The  problems  of  distributed  systems  technology  need  a long,  hard  look 
by  both  the  military  and  private  industry,  and  good  solutions  must  be 


developed.  An  initial  attempt  at  this  by  the  Navy  was  the  Navy  Dis- 
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